7장 세 가지 작업 모드 (입문판)

출처: 클로드 코드 완벽 가이드 (코드팩토리 최지호)

이 장에서 딱 3가지만 1. 일반 모드 — 하나하나 확인하며 쓰는 기본 모드 2. 자동 수정 모드 — 클로드 코드가 알아서 척척 고치는 모드 3. 플래닝 모드 — 코드를 짜기 전에 계획부터 세우는 모드 이 세 모드를 Shift+Tab 한 번으로 바꿔 쓰는 게 핵심입니다.

이 장에서 우리가 할 수 있게 되는 것

• 클로드 코드의 세 가지 모드가 어떻게 다른지 설명한다.
• 상황에 맞는 모드를 구분한다.
• Shift+Tab으로 모드를 바꾸는 법을 따라 한다.

참고로 이 장은 클로드 코드의 요금제, 모델명, 버튼 문구 같은 세부 사항이 시간이 지나면 바뀔 수 있습니다. 여기 나온 화면 문구나 옵션 이름은 원서/노트 기준 예시이며, 최신 값은 공식 문서(클로드 코드 공식 문서: https://docs.anthropic.com/en/docs/claude-code)에서 확인하세요.

시작 전 준비 — 이건 알고 오면 좋아요

긴 여행을 떠나기 전에 가방을 한 번 확인하죠. 여권 챙겼나, 표는 있나, 충전기는 넣었나. 빠뜨린 게 있으면 공항에서 당황하니까요.

이 장도 똑같습니다. 아래 세 가지가 준비됐는지 가볍게 점검하고 오면, 막히지 않고 술술 읽힙니다. 다 못 챙겼어도 괜찮습니다. 어디서 채우면 되는지 옆에 적어 뒀어요.

용어 한 줄 메모: '터미널(CLI)'이란 마우스 클릭 대신 글자 명령을 쳐서 컴퓨터에 일을 시키는 까만 입력 창입니다. 식당에서 메뉴판을 손가락으로 가리키는 대신, 말로 "김치찌개 주세요"라고 주문하는 것과 같습니다.

용어 한 줄 메모: 'CLAUDE.md'란 클로드 코드가 일을 시작하기 전에 먼저 읽는 약속 메모입니다. 새 알바생에게 "우리 가게는 이렇게 해요"라고 적어 붙여둔 안내문 같은 것이고, 6장에서 다룬 내용이니 가물가물하면 6장을 다시 보세요.

세 칸에 다 체크가 됐다면 준비 끝입니다. 이제 본격적으로 시작해 볼까요.

들어가기 전에 — 모드가 왜 필요할까

이런 적 있죠?

운전을 배울 때를 떠올려 봅시다. 처음엔 천천히, 기어 하나하나 바꿔가며 조심조심 갑니다. 익숙해지면 자동 기어로 휙휙 달리죠. 그런데 어디로 갈지 모를 땐, 일단 멈춰서 지도부터 봅니다.

클로드 코드도 똑같습니다. 때로는 하나씩 확인하고 싶고, 때로는 빠르게 처리하고 싶고, 때로는 계획부터 세우고 싶습니다. 그래서 클로드 코드는 상황에 맞춰 쓸 수 있게 세 가지 모드를 줍니다. 그 세 가지가 바로 일반 모드, 자동 수정 모드, 플래닝 모드입니다.

용어 한 줄 메모: '모드'란 같은 도구가 상황에 따라 다르게 동작하는 '작동 방식'을 말합니다. 선풍기의 약풍/강풍 버튼처럼, 같은 선풍기라도 누른 버튼에 따라 바람 세기가 달라지는 것과 같습니다.

이 세 모드를 머릿속에 그려두면 됩니다.

[일반 모드]  →  [자동 수정 모드]  →  [플래닝 모드]  →  다시 [일반 모드]
 하나씩 확인       알아서 수정          계획만 세움

Shift+Tab 키를 누를 때마다 이 순서로 빙글빙글 돌아갑니다. (Shift+Tab은 키보드의 Shift 키를 누른 채로 Tab 키를 같이 누르는 동작입니다.)

용어 한 줄 메모: '콘텍스트 윈도우'란 클로드 코드가 한 번에 기억하고 다룰 수 있는 글의 양 한계를 말합니다. 한 손에 들 수 있는 책 권수가 정해진 것처럼, 너무 많은 내용을 한꺼번에 주면 일부를 놓칩니다. 6장에서 다룬 개념이니 가물가물하면 6장을 다시 보세요.

7.1 하나하나 확인하고 싶을 때 — 일반 모드

이런 적 있죠?

요리를 처음 배울 때를 떠올려 봅시다. 누가 "알아서 다 해놨어, 먹어"라고 하면, 맛이 이상해도 뭘 잘못 넣었는지 알 수가 없습니다. 반대로 "소금 한 스푼 넣을까요?" "네!" "그다음 후추는요?" "네!" 이렇게 한 단계씩 확인하며 배우면, 내가 뭘 하고 있는지 정확히 압니다.

그게 바로 일반 모드입니다.

일반 모드는 클로드 코드가 "이렇게 고칠까요?" 하고 물어보면, 내가 보고 결정하는 방식입니다. 클로드 코드를 처음 켜면 자동으로 이 일반 모드로 시작합니다. 별다른 전환이 필요 없는 기본 상태입니다.

고치자고 할 때 나오는 3가지 선택지

클로드 코드가 코드를 고치겠다고 제안하면, 화면에 세 가지 선택지가 나옵니다.

말로 풀면 이렇습니다.

• 1번은 "그래, 좋아!" 입니다.
• 2번은 "좋아, 이제 일일이 안 물어봐도 돼" 입니다. 이걸 누르면 다음에 설명할 자동 수정 모드로 넘어갑니다.
• 3번은 "아니, 이렇게 말고 저렇게 해줘" 입니다.

용어 한 줄 메모: 'Esc'는 키보드 맨 왼쪽 위에 있는 키로, '취소'나 '뒤로'를 뜻합니다. 게임에서 메뉴를 닫을 때 누르는 그 키와 같습니다.

일반 모드가 딱 좋은 상황 5가지

1. 처음 써보는 라이브러리나 프레임워크를 배울 때. 한 줄씩 보며 사용법을 익힐 수 있습니다.
2. 같은 기능을 여러 방법으로 만들어 보며 비교하고 싶을 때.
3. 오류 메시지가 무슨 뜻인지 정확히 알고 싶을 때.
4. 내가 짠 코드를 누군가에게 점검받듯 코드 리뷰를 받고 싶을 때.
5. 아직 클로드 코드를 완전히 믿기 전이라 하나씩 직접 확인하고 싶을 때.

용어 한 줄 메모: '라이브러리'란 남이 미리 만들어 둔 코드 묶음으로, 필요할 때 가져다 쓰는 부품 상자입니다. '프레임워크'는 그 부품을 끼워 넣는 틀, 즉 집을 지을 때의 골조 같은 것입니다.

용어 한 줄 메모: '코드 리뷰'란 내가 짠 코드를 다른 사람(혹은 클로드 코드)이 살펴보며 문제점이나 개선점을 짚어주는 일입니다. 글 쓴 뒤 다른 사람에게 맞춤법 봐달라고 하는 것과 같습니다.

따라 해 보기 — 화면에서 수정 내용 비교 보기 (Diff)

일반 모드의 큰 장점은 무엇이 바뀌는지 눈으로 확인할 수 있다는 점입니다. IDE 플러그인을 연결하면, 바뀌기 전과 후를 나란히 보여주는 'Diff' 화면을 볼 수 있습니다.

용어 한 줄 메모: 'IDE'란 코드를 쓰는 전문 편집 프로그램입니다(예: VS Code). '플러그인'은 그 프로그램에 끼워 기능을 더하는 부속품으로, 휴대폰 케이스에 붙이는 추가 액세서리 같은 것입니다.

용어 한 줄 메모: 'Diff'는 영어 difference(차이)의 줄임말로, 바뀌기 전 코드와 바뀐 후 코드의 '다른 점'만 비교해 보여주는 기능입니다. 틀린 그림 찾기처럼, 어디가 달라졌는지 한눈에 보여줍니다.

실제로는 이런 흐름입니다.

1. 클로드 코드에게 고쳐달라고 부탁합니다.

> crypto-ranking-board.tsx의 제목을 한글로 변경해줘

1. 클로드 코드가 이렇게 고치겠다고 비교 화면을 보여줍니다.

132  - | Cryptocurrency Rankings     (지워질 줄)
     132  + | 암호화폐 순위              (새로 들어갈 줄)

윗줄에 빼기(-) 표시가 붙은 줄은 사라질 줄이고, 아래에 더하기(+) 표시가 붙은 줄은 새로 들어올 줄입니다.

1. 내가 보고 결정합니다.
2. 마음에 들면 Yes를 눌러 적용합니다.
3. 아니면 "영어는 그대로 두고 부제목에만 한글 추가해줘"처럼 다시 알려줍니다.

이렇게 바뀌는 부분을 눈으로 확인하고 넘어갈 수 있어서, 배우거나 점검할 때 아주 좋습니다.

잘못된 예 vs 올바른 예

잘못된 예: 처음부터 끝까지 무조건 일반 모드만 고집한다.

모든 작업을 일반 모드로만 → 매번 "Yes? Yes? Yes?" 확인만 하다 지침

이렇게 하면 클로드 코드가 가진 힘의 1%만 쓰는 셈입니다. 배우거나 디버깅할 땐 좋지만, 일이 빨리 안 됩니다.

올바른 예: 일반 모드로 충분히 익힌 다음, 상황에 맞게 다른 모드도 적극적으로 쓴다.

새 기술 배울 땐 일반 모드로 천천히
  → 익숙해지면 자동 수정 모드, 플래닝 모드로 빠르게

용어 한 줄 메모: '디버깅'이란 코드에 생긴 오류(버그)를 찾아 고치는 일입니다. 고장 난 가전제품의 어디가 문제인지 하나씩 짚어보는 것과 같습니다.

이럴 땐 이렇게 (미니 시나리오)

상황: React Query라는 처음 보는 도구가 어떻게 동작하는지 궁금합니다.

이렇게 하세요: 일반 모드 그대로 둡니다. 클로드 코드가 코드를 한 줄씩 제안할 때마다 Yes를 누르며, 무슨 일이 벌어지는지 직접 보면서 배웁니다.

여기까지 체크

• 일반 모드는 클로드 코드의 기본 상태이고, 처음 켜면 자동으로 이 모드입니다.
• 고치자고 할 때 Yes / Shift+Tab(자동 승인) / Esc(거절) 세 가지 중에 고릅니다.
• IDE 플러그인을 연결하면 Diff로 바뀌는 부분을 눈으로 확인할 수 있습니다.
• 무조건 일반 모드만 쓰면 클로드 코드 성능의 1%만 쓰는 것과 같습니다.

7.2 반복 작업을 빠르게 — 자동 수정 모드

이런 적 있죠?

스무 군데에 똑같이 적어야 하는 단순 작업을 떠올려 봅시다. "여기 이름 바꾸고, 저기도 바꾸고, 또 저기도…" 매번 "바꿀까요?" "네" "바꿀까요?" "네"를 반복하면 손가락이 아픕니다. 이럴 땐 "그냥 다 알아서 바꿔줘"가 훨씬 편합니다.

그게 바로 자동 수정 모드입니다.

자동 수정 모드는 클로드 코드가 일일이 묻지 않고 알아서 코드를 고치는 모드입니다. 화면에는 'auto-accept edits on'이라는 문구로 표시됩니다. (auto-accept edits는 '수정을 자동으로 받아들인다'는 뜻입니다.)

핵심은 이겁니다. 무엇을 해야 할지가 분명하고 단순 반복일 때만 자동 수정 모드를 씁니다.

자동 수정 모드로 바꾸는 법

일반 모드에서 Shift+Tab을 한 번 누릅니다. 화면 아래에 'auto-accept edits on' 메시지가 뜨면 전환 완료입니다.

> ▌
▸▸ auto-accept edits on (shift+tab to cycle)

여기서 'shift+tab to cycle'은 "Shift+Tab을 또 누르면 다음 모드로 넘어갑니다"라는 안내입니다.

자동 수정 모드가 딱 좋은 상황 5가지

1. 변수명, 함수명, 클래스명을 프로젝트 전체에서 한꺼번에 바꿀 때 (리네이밍).
2. 기존 코드를 더 깔끔한 형태로 다듬을 때 (리팩터링).
3. 함수나 클래스에 설명 주석을 다는 문서 작업(JSDoc 등)을 할 때.
4. 똑같은 패턴의 단순 작업을 여러 파일에 반복할 때.
5. 테스트 코드를 작성할 때. 분량이 아무리 많아도 안전합니다.

용어 한 줄 메모: '리네이밍'은 이름 바꾸기입니다. 폴더 안 사진 파일 이름을 한꺼번에 바꾸는 것과 같습니다.

용어 한 줄 메모: '리팩터링'은 동작은 그대로 두고 코드를 더 보기 좋고 다루기 쉽게 정리하는 일입니다. 방 안 물건 위치를 정리해 쓰기 편하게 만드는 것과 같습니다.

용어 한 줄 메모: '테스트 코드'란 내가 만든 기능이 제대로 작동하는지 자동으로 검사해 주는 코드입니다. 새 자전거를 사면 브레이크가 잘 듣는지 미리 눌러보는 것과 같습니다.

용어 한 줄 메모: 'JSDoc'은 자바스크립트 함수 위에 "이 함수는 무엇을 한다"를 정해진 형식으로 적는 설명 주석입니다. 약통에 붙은 복용 안내문 같은 것입니다.

따라 해 보기 — 테스트 코드 자동으로 만들기

자동 수정 모드는 테스트 코드 만들 때 특히 빛납니다.

> 현재 프로젝트에 테스트코드를 추가해줘

● 프로젝트에 테스트 코드를 추가하겠습니다.

● 할 일 목록
  □ 현재 상태 확인 및 테스트 프레임워크 결정
  □ 테스트 프레임워크와 필요한 패키지 설치
  □ 컴포넌트 테스트 작성
  □ 설정 파일 생성
  □ 유틸리티 함수 테스트 작성

이렇게 부탁만 하면, 클로드 코드가 묻지 않고 알아서 파일을 만들고, 필요한 도구를 설치하고, 테스트까지 척척 써 내려갑니다.

주의할 점 — 자동이라 더 조심

자동 수정 모드는 편하지만 위험도 있습니다.

첫째, 나와 클로드 코드의 생각이 어긋날 수 있습니다. 내가 원한 것과 다르게 고쳐도 중간에 막을 기회가 없습니다.

둘째, 콘텍스트 윈도우 한계 문제입니다. 자동 수정 모드라도 한 번에 다룰 수 있는 양을 넘어서면, 클로드 코드가 앞 내용을 잊고 흐름을 잃습니다.

그래서 자동 수정 모드는 이런 원칙을 지킬 때만 씁니다.

1. 작업이 길고 복잡한 맥락을 필요로 하지 않을 것.
2. 단순 반복 작업일 것.
3. 무엇을 만들지 요구사항이 이미 또렷하게 정리돼 있을 것 (PRD).
4. 테스트 코드는 분량이 아무리 많아도 괜찮습니다. 프로젝트 본체를 망치지 않으니까요.

용어 한 줄 메모: 'PRD'는 Product Requirements Document(제품 요구사항 문서)의 줄임말로, "무엇을 어떻게 만들지" 미리 정리한 설명서입니다. 집 짓기 전 건축주가 적어주는 요구사항 메모 같은 것입니다.

잘못된 예 vs 올바른 예

잘못된 예: 무엇을 원하는지 흐릿한데 자동 수정 모드로 큰 기능을 통째로 맡긴다.

> 결제 시스템 알아서 다 만들어줘   (자동 수정 모드)
→ 내가 원하던 것과 전혀 다른 방향으로 다 만들어 버림

올바른 예: 요구사항이 또렷한 단순 반복 작업만 자동 수정 모드에 맡긴다.

> 프로젝트 전체에서 user_name을 userName으로 모두 바꿔줘   (자동 수정 모드)
→ 명확한 작업이라 안심하고 맡길 수 있음

이럴 땐 이렇게 (미니 시나리오)

상황: 이미 디자인이 다 정해진 컴포넌트 10개를 만들어야 합니다.

이렇게 하세요: Shift+Tab으로 자동 수정 모드로 바꾸고, "이 디자인대로 컴포넌트 10개 만들어줘"라고 부탁합니다. 요구사항이 분명하니 빠르게 처리됩니다.

여기까지 체크

• Shift+Tab을 한 번 눌러 자동 수정 모드로 바꿉니다 ('auto-accept edits on' 확인).
• 묻지 않고 알아서 고치므로 주의가 필요합니다.
• 콘텍스트 윈도우 한계를 넘으면 흐름을 잃을 수 있습니다.
• 테스트 코드 작성은 자동 수정 모드와 궁합이 아주 좋습니다.

7.3 코드 짜기 전에 계획부터 — 플래닝 모드

이런 적 있죠?

집을 지을 때를 떠올려 봅시다. 설계도 없이 일단 벽돌부터 쌓으면, 나중에 구조가 흔들려 다 뜯어고치게 됩니다. 먼저 설계도를 꼼꼼히 그려두면, 차근차근 안정적으로 지을 수 있습니다.

그게 바로 플래닝 모드입니다.

플래닝 모드는 코드를 짜지 않고, 무엇을 어떻게 만들지 계획만 세우는 모드입니다. 화면에는 'plan mode on'이라는 문구로 표시됩니다. (plan mode는 '계획 모드'라는 뜻입니다.)

저자는 이 플래닝 모드를 클로드 코드의 가장 핵심적인 기능이라고 강조합니다.

플래닝 모드로 바꾸는 법

Shift+Tab을 눌러 모드를 돌립니다.

일반 모드 → 자동 수정 모드 → 플래닝 모드 → 다시 일반 모드 → ...

플래닝 모드는 일반 모드에서 Shift+Tab을 두 번 누르면 나옵니다. 화면 아래에 'plan mode on' 메시지가 뜨면 전환 완료입니다.

> ▌
‖ plan mode on (shift+tab to cycle)

사용법 — 막연한 질문을 활짝 던지기

플래닝 모드에는 정답을 콕 집어 묻기보다, 넓게 물어보는 게 좋습니다.

> 인증 시스템을 구현하고 싶은데 어떻게 하면 좋을까?
  몇 가지 방법을 추천해줘

그러면 클로드 코드가 단계별 계획을 정리해 줍니다.

1. NextAuth.js 설치 및 기본 설정
2. 인증 제공자 설정 (Google OAuth, GitHub OAuth 등)
3. 세션 관리 구현
4. UI 컴포넌트 생성
5. 데이터베이스 연동
6. 보안 강화

그리고 마지막에 "이 계획대로 진행할까요? (Would you like to proceed?)"라고 묻습니다.

용어 한 줄 메모: '인증 시스템'이란 "이 사람이 진짜 그 사람이 맞나"를 확인하고 로그인을 처리하는 장치입니다. 건물 입구에서 출입증을 확인하는 경비실 같은 것입니다.

용어 한 줄 메모: 'OAuth'는 구글이나 깃허브 같은 다른 서비스 계정으로 간편하게 로그인하게 해주는 방식입니다. 놀이공원에서 다른 곳 회원카드로 입장하는 것과 비슷합니다.

핵심 노하우 — [Yes]를 바로 누르지 마세요!

여기가 이 장에서 가장 중요한 부분입니다.

저자는 이렇게 조언합니다. "저는 첫 번째 계획에 [Yes]를 바로 선택하지 않는 것을 추천합니다."

왜냐하면 첫 계획은 보통 막연하기 때문입니다. 대신 [No, keep planning]을 골라 계획을 더 다듬는 게 좋습니다. (keep planning은 '계획을 계속 세운다'는 뜻입니다.)

플래닝 모드를 잘 쓰는 흐름은 이렇습니다.

1단계: 막연한 질문 던지기
  → "인증 시스템 만들고 싶은데 추천해줘"

2단계: 첫 계획 확인
  → "진행할까요?"
  → [Yes] 바로 누르기 (X)
  → [No, keep planning] 고르기 (O)

3단계: 더 구체적인 요구사항 추가하기
  → "Prisma + PostgreSQL로 하고, Zustand로 인증 상태 관리해줘"

4단계: 더 탄탄해진 계획 다시 확인
  → 패키지, 모델, 라우트, UI까지 상세하게 나옴
  → 또 [No]로 다듬거나, 만족하면 [Yes]

5단계: 충분히 구체적이면 그때 [Yes]

[Yes]를 바로 누르면 안 되는 3가지 이유

따라 해 보기 — 막연한 계획에서 구체적인 계획으로

1차 계획은 보통 막연합니다.

[1차 계획 — 막연함]
NextAuth.js를 사용한 인증 시스템 구현 계획
1. NextAuth.js 설치 및 기본 설정
2. 인증 제공자 설정
   - Google OAuth (가장 일반적)
   - GitHub OAuth (개발자 친화적)
   - 이메일/비밀번호 인증 옵션

→ 어떤 데이터베이스를 쓸지, 상태 관리는 어떻게 할지 안 정해짐
→ [No, keep planning]을 골라 구체화!

요구사항을 더 보태면 계획이 또렷해집니다.

[2차 계획 — 구체적]
(요구사항: "Prisma + PostgreSQL, Zustand 사용해줘")

Prisma + PostgreSQL (Supabase) 인증 시스템 구현 계획
1. 필요한 패키지 설치
   - @prisma/client, prisma  (ORM)
   - bcryptjs  (비밀번호 해싱)
   - jsonwebtoken  (JWT 토큰 생성/검증)
2. Supabase 프로젝트 설정
   - PostgreSQL 연결 URL 획득
   - 환경 변수 설정 (.env.local)
3. Supabase 클라이언트 설정
4. Zustand 스토어 구현 (인증 상태 관리)
5. 인증 Provider 구현
6. UI 컴포넌트 생성
7. 페이지 생성
8. 미들웨어 설정
9. 레이아웃 업데이트

→ 매우 구체적! 이 정도면 [Yes]를 골라도 OK!

용어 한 줄 메모: '데이터베이스'는 정보를 차곡차곡 모아 두는 큰 창고입니다. 'ORM'은 그 창고의 데이터를 코드에서 편하게 다루도록 이어주는 통역사 같은 도구입니다.

용어 한 줄 메모: '상태 관리'란 화면이 기억해야 할 정보(예: 지금 로그인한 사람)를 일관되게 보관하고 나눠 쓰는 일입니다. 가게의 공용 화이트보드에 현재 상황을 적어두고 모두가 같이 보는 것과 같습니다.

계획이 너무 클 때 — 잘게 나누기

계획이 너무 크면 제어할 수 있는 크기로 나눠서 진행하는 게 좋습니다.

[잘못된 예] 큰 계획을 깃허브 이슈 하나에 통째로
→ 콘텍스트가 터져 클로드 코드가 흐름을 잃음

[올바른 예] 깃허브 이슈로 나누기
1. 이메일 인증 → 이슈 #1
2. Google OAuth 인증 → 이슈 #2
3. GitHub OAuth 인증 → 이슈 #3
→ 하나씩 다루니 효율적!

용어 한 줄 메모: '깃허브 이슈'란 깃허브에서 "이 작업을 해야 한다"를 한 건씩 적어두는 할 일 카드입니다. 냉장고에 붙여둔 포스트잇 할 일 메모 같은 것입니다. (깃허브와 Git 기본 개념은 미리 알아두면 좋습니다.)

클로드 코드는 코딩 파트너입니다

클로드 코드를 쓰는 건, 함께 일하는 동료와 협업하는 것과 같습니다.

[잘못된 예] "알아서 다 해줘"
→ 내 의도와 다른 결과

[올바른 예] "이 기술을 쓰고, 이 구조로, 이 범위만 해줘"
→ 작업 규모를 정해주고 함께 만들어 가면 효율적!

이럴 땐 이렇게 (미니 시나리오)

상황: 새로운 결제 시스템을 만들어야 하는데 어디서부터 시작할지 막막합니다.

이렇게 하세요: Shift+Tab을 두 번 눌러 플래닝 모드로 들어갑니다. "결제 시스템을 만들고 싶은데 방법을 추천해줘"라고 넓게 묻고, 첫 계획엔 [No, keep planning]으로 답하며 기술과 범위를 정해 갑니다. 충분히 구체적이 되면 그때 [Yes].

여기까지 체크

• 플래닝 모드는 코드를 짜지 않고 계획만 세우는 모드입니다.
• 막연한 기능이 있을 땐 일단 플래닝 모드로 들어갑니다.
• 첫 계획에 바로 [Yes]를 누르지 말고 [No, keep planning]으로 구체화합니다.
• 계획이 너무 크면 깃허브 이슈 단위로 잘게 나눕니다.
• 저자는 플래닝 모드를 클로드 코드의 "가장 핵심적인 기능"이라 평가합니다.

세 모드 한눈에 비교

종합 비교표

상황별 추천 가이드

연습 문제

문제 1 — 어떤 모드를 쓸까 (기본)

각 상황에 맞는 모드를 골라보세요.

정답 - A: 일반 모드 (새 기술을 하나씩 확인하며 배워야 하므로) - B: 자동 수정 모드 (단순 반복 리네이밍이므로) - C: 플래닝 모드 (구현 전에 설계와 기술 선택이 먼저이므로) - D: 일반 모드 (오류 뜻을 정확히 알고 싶은 학습/디버깅이므로) - E: 자동 수정 모드 (요구사항이 명확한 반복 생성이므로)

문제 2 — 플래닝 모드 실전 (중급)

아래는 플래닝 모드에서 받은 첫 계획입니다. 문제점 3가지를 찾고, [No, keep planning]과 함께 어떤 요구사항을 더 넣을지 적어보세요.

블로그 시스템 구현 계획
1. Next.js + TypeScript 기본 설정
2. 데이터베이스 연동 (MongoDB or PostgreSQL)
3. 인증 시스템 (NextAuth.js)
4. 게시글 CRUD
5. 댓글 시스템
6. 태그/카테고리
7. 검색 기능
8. SEO 최적화
9. 다크모드
10. 반응형 디자인

정답 예시 - 문제점 1 (DB 미결정): "MongoDB or PostgreSQL"로 도구가 정해지지 않아 클로드 코드가 멋대로 고를 수 있습니다. - 문제점 2 (범위 과다): 인증, 댓글, 검색, SEO까지 한 번에 하면 콘텍스트 한계에 걸립니다. - 문제점 3 (구체성 부족): 패키지, 파일 구조, 모델 정의가 전혀 없습니다. - 추가 요구사항 예시: "PostgreSQL + Prisma로 하고, 우선 게시글 CRUD만 먼저 만들어줘. 인증은 다음 단계에서 따로 할게. 파일 구조와 모델도 구체적으로 보여줘."

문제 3 — 모드 전환 순서 (기본)

Shift+Tab을 누를 때마다 모드가 어떤 순서로 바뀌는지 빈칸을 채우세요.

(   ) 모드 → (   ) 모드 → (   ) 모드 → 다시 (   ) 모드 → ...

정답

( 일반 ) 모드 → ( 자동 수정 ) 모드 → ( 플래닝 ) 모드 → 다시 ( 일반 ) 모드 → ...

Shift+Tab은 세 모드를 빙글빙글 도는 단축키입니다.

이 장에서 새로 배운 말 (미니 용어집)

다음 장 예고

다음 장에서는 클로드 코드를 더 똑똑하게 쓰는 또 다른 기능을 다룹니다. 지금 몰라도 됩니다.